4.1.1. AES in Counter Mode (AES im Zählermodus)
4.1.1. AES in Counter Mode (AES im Zählermodus)
Konzeptionell besteht der Zählermodus [AES-CTR] aus der Verschlüsselung aufeinanderfolgender Ganzzahlen. Die tatsächliche Definition ist etwas komplizierter, um den Startpunkt der Ganzzahlsequenz zu randomisieren. Jedes Paket wird mit einem eindeutigen Schlüsselstromsegment verschlüsselt, das wie folgt berechnet werden SOLL.
Ein Schlüsselstromsegment SOLL die Verkettung der 128-Bit-Ausgabeblöcke der AES-Chiffre in Verschlüsselungsrichtung sein, unter Verwendung des Schlüssels k = k_e, wobei die Blockindizes in aufsteigender Reihenfolge sind. Symbolisch sieht jedes Schlüsselstromsegment wie folgt aus
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
wobei der 128-Bit-Ganzzahlwert IV durch den SSRC, den SRTP-Paketindex i und den SRTP-Sitzungssalzschlüssel k_s wie folgt definiert werden SOLL.
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
Jeder der drei Terme in der obigen XOR-Summe wird mit so vielen führenden Nullen aufgefüllt, wie benötigt werden, um die Operation wohldefiniert zu machen, betrachtet als 128-Bit-Wert.
Die Einbeziehung des SSRC ermöglicht die Verwendung desselben Schlüssels zum Schutz unterschiedlicher SRTP-Ströme innerhalb derselben RTP-Sitzung, siehe die Sicherheitshinweise in Abschnitt 9.1.
Im Fall von SRTCP MUSS der SSRC des ersten Headers des zusammengesetzten Pakets verwendet werden, i SOLL der 31-Bit-SRTCP-Index sein und k_e, k_s SOLLEN durch den SRTCP-Verschlüsselungs-Sitzungsschlüssel und das Salz ersetzt werden.
Beachten Sie, dass der Anfangswert IV für jedes Paket fest ist und durch "Reservieren" von 16 Nullen in den am wenigsten signifikanten Bits für Zwecke des Zählers gebildet wird. Die Anzahl der für einen beliebigen festen Wert von IV generierten Schlüsselstromblöcke DARF 2^16 NICHT überschreiten, um eine Wiederverwendung des Schlüsselstroms zu vermeiden, siehe unten. AES hat eine Blockgröße von 128 Bits, sodass 2^16 Ausgabeblöcke ausreichen, um die 2^23 Bits Schlüsselstrom zu generieren, die zum Verschlüsseln des größtmöglichen RTP-Pakets benötigt werden (außer für IPv6-"Jumbogramme" [RFC2675], die wahrscheinlich nicht für RTP-basierten Multimediadatenverkehr verwendet werden). Diese Beschränkung der maximalen Bitgröße des Pakets, das verschlüsselt werden kann, gewährleistet die Sicherheit der Verschlüsselungsmethode, indem die Wirksamkeit probabilistischer Angriffe begrenzt wird [BDJR].
Für einen bestimmten Zählermodusschlüssel MUSS jeder als Eingabe verwendete IV-Wert eindeutig sein, um die Sicherheitsgefährdung einer Two-Time-Pad-Situation zu vermeiden (Abschnitt 9.1). Um diese Einschränkung zu erfüllen, MUSS eine Implementierung sicherstellen, dass die Kombination des SRTP-Paketindex von ROC || SEQ und des SSRC, der bei der Konstruktion des IV verwendet wird, für jeden bestimmten Schlüssel eindeutig sind. Das Versäumnis, diese Eindeutigkeit sicherzustellen, könnte für Secure RTP katastrophal sein. Dies steht im Gegensatz zur Situation bei RTP selbst, das möglicherweise in der Lage ist, solche Ausfälle zu tolerieren. Es wird EMPFOHLEN, dass, wenn ein dediziertes Sicherheitsmodul vorhanden ist, die RTP-Sequenznummern und der SSRC entweder von diesem Modul generiert oder überprüft werden (d. h., die Verarbeitung von Sequenznummern und SSRC in einem SRTP-System muss ebenso wie der Schlüssel geschützt werden).