3.1. Secure RTP (Sicheres RTP)
3.1. Secure RTP (Sicheres RTP)
Das Format eines SRTP-Pakets ist in Abbildung 1 dargestellt.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
|V=2|P|X| CC |M| PT | sequence number | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| timestamp | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| synchronization source (SSRC) identifier | |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |
| contributing source (CSRC) identifiers | |
| .... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| RTP extension (OPTIONAL) | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | payload ... | |
| | +-------------------------------+ |
| | | RTP padding | RTP pad count | |
+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+
| ~ SRTP MKI (OPTIONAL) ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| : authentication tag (RECOMMENDED) : |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+- Encrypted Portion* Authenticated Portion ---+
Abbildung 1. Das Format eines SRTP-Pakets. *Der verschlüsselte Teil hat die gleiche Größe wie der Klartext für die in Abschnitt 4 vordefinierten Transformationen.
Der "Encrypted Portion" (Verschlüsselte Teil) eines SRTP-Pakets besteht aus der Verschlüsselung der RTP-Nutzdaten (einschließlich RTP-Padding, falls vorhanden) des äquivalenten RTP-Pakets. Der verschlüsselte Teil KANN genau die Größe des Klartexts haben oder KANN größer sein. Abbildung 1 zeigt die RTP-Nutzdaten einschließlich jeglicher möglicher Auffüllung für RTP [RFC3550].
Keine der vordefinierten Verschlüsselungstransformationen verwendet Padding; für diese stimmen die RTP- und SRTP-Nutzdatengrößen genau überein. Neue zu SRTP hinzugefügte Transformationen (gemäß Abschnitt 6) können Padding erfordern und daher größere Nutzdaten erzeugen. RTP bietet ein eigenes Padding-Format (wie in Abb. 1 zu sehen), das aufgrund des Padding-Indikators im RTP-Header Vorteile in Bezug auf Kompaktheit gegenüber Paddings mit präfixfreien Codes hat. Dieses RTP-Padding MUSS die Standardmethode für Transformationen sein, die Padding erfordern. Transformationen KÖNNEN andere Padding-Methoden spezifizieren und MÜSSEN dann die Menge, das Format und die Verarbeitung ihres Paddings spezifizieren. Es ist wichtig zu beachten, dass Verschlüsselungstransformationen, die Padding verwenden, anfällig für subtile Angriffe sind, insbesondere wenn keine Nachrichtenauthentifizierung verwendet wird [V02]. Jede Spezifikation für eine neue Verschlüsselungstransformation muss die Sicherheitsauswirkungen des verwendeten Paddings sorgfältig berücksichtigen und beschreiben. Nachrichtenauthentifizierungscodes definieren ihr eigenes Padding, daher gilt dieser Standard nicht für Authentifizierungstransformationen.
Der OPTIONALE MKI und das EMPFOHLENE authentication tag sind die einzigen von SRTP definierten Felder, die nicht in RTP vorhanden sind. Es wird nur eine 8-Bit-Ausrichtung angenommen.
MKI (Master Key Identifier, Hauptschlüsselidentifikator): konfigurierbare Länge, OPTIONAL. Der MKI wird von der Schlüsselverwaltung definiert, signalisiert und verwendet. Der MKI identifiziert den Hauptschlüssel, von dem die Sitzungsschlüssel abgeleitet wurden, die das bestimmte Paket authentifizieren und/oder verschlüsseln. Beachten Sie, dass der MKI NICHT den SRTP-Kryptographiekontext identifizieren DARF, der gemäß Abschnitt 3.2.3 identifiziert wird. Der MKI KANN von der Schlüsselverwaltung für die Zwecke der Neuverschlüsselung verwendet werden, um einen bestimmten Hauptschlüssel innerhalb des Kryptographiekontexts zu identifizieren (Abschnitt 3.2.1).
Authentication tag (Authentifizierungs-Tag): konfigurierbare Länge, EMPFOHLEN. Das authentication tag wird verwendet, um Nachrichtenauthentifizierungsdaten zu übertragen. Der Authenticated Portion (Authentifizierte Teil) eines SRTP-Pakets besteht aus dem RTP-Header gefolgt vom verschlüsselten Teil des SRTP-Pakets. Wenn sowohl Verschlüsselung als auch Authentifizierung angewendet werden, MUSS daher auf der Senderseite die Verschlüsselung vor der Authentifizierung angewendet werden und auf der Empfängerseite umgekehrt. Das authentication tag bietet Authentifizierung des RTP-Headers und der Nutzdaten und bietet indirekt Replay-Schutz durch Authentifizierung der Sequenznummer. Beachten Sie, dass der MKI nicht integritätsgeschützt ist, da dies keinen zusätzlichen Schutz bietet.