9.1. SSRC collision and two-time pad (SSRC-Kollision und Two-Time-Pad)
9.1. SSRC collision and two-time pad (SSRC-Kollision und Two-Time-Pad)
Jede feste Schlüsselstromausgabe, die aus demselben Schlüssel und Index generiert wird, DARF nur einmal zur Verschlüsselung verwendet werden. Die Wiederverwendung eines solchen Schlüsselstroms (von Kryptographen scherzhaft als "Two-Time-Pad"-System bezeichnet) kann die Sicherheit ernsthaft gefährden. Das VENONA-Projekt der NSA [C99] bietet ein historisches Beispiel für eine solche Kompromittierung. Es ist ERFORDERLICH, dass automatische Schlüsselverwaltung zur Etablierung und Aufrechterhaltung von SRTP- und SRTCP-Schlüsselmaterial verwendet wird; diese Anforderung dient der Vermeidung der Schlüsselstrom-Wiederverwendung, die bei manueller Schlüsselverwaltung wahrscheinlicher ist. Darüber hinaus wird in SRTP ein "Two-Time-Pad" vermieden, indem verlangt wird, dass der Schlüssel oder ein anderer kryptografisch bedeutsamer Parameter pro RTP/RTCP-Stream und Paket eindeutig ist. Die vordefinierten SRTP-Transformationen erreichen Paket-Eindeutigkeit durch Einbeziehung des Paketindex und Stream-Eindeutigkeit durch Einbeziehung des SSRC.
Die vordefinierten Transformationen (AES-CM und AES-f8) erlauben das Teilen von Hauptschlüsseln zwischen Streams, die zur selben RTP-Sitzung gehören, durch Einbeziehung des SSRC im IV. Ein Hauptschlüssel DARF NICHT zwischen verschiedenen RTP-Sitzungen geteilt werden.
Daher MUSS der SSRC zwischen allen RTP-Streams innerhalb derselben RTP-Sitzung, die denselben Hauptschlüssel teilen, eindeutig sein. RTP selbst bietet einen Algorithmus zur Erkennung von SSRC-Kollisionen innerhalb derselben RTP-Sitzung. Somit könnten temporäre Kollisionen zu temporärem Two-Time-Pad führen, im unglücklichen Fall, dass SSRCs zu einem Zeitpunkt kollidieren, an dem die Streams auch identische Sequenznummern haben (mit einer Wahrscheinlichkeit von ungefähr 2^(-48)). Daher SOLLTE die Schlüsselverwaltung darauf achten, solche SSRC-Kollisionen zu vermeiden, indem die in der Sitzung zu verwendenden SSRCs als Verhandlungsparameter einbezogen werden und proaktiv deren Eindeutigkeit sichergestellt wird. Dies ist eine starke Anforderung in Szenarien, in denen es beispielsweise mehrere Sender gibt, die gleichzeitig zu übertragen beginnen können, bevor SSRC-Kollisionen auf RTP-Ebene erkannt werden.
Beachten Sie auch, dass selbst bei unterschiedlichen SSRCs die extensive Verwendung desselben Schlüssels die Chancen für probabilistische Kollisions- und Zeit-Speicher-Kompromiss-Angriffe erhöhen könnte.
Wie beschrieben, KÖNNEN Hauptschlüssel zwischen Streams, die zur selben RTP-Sitzung gehören, geteilt werden, aber es wird EMPFOHLEN, dass jeder SSRC seinen eigenen Hauptschlüssel hat. Wenn Hauptschlüssel zwischen SSRC-Teilnehmern geteilt werden und SSRCs von einem Schlüsselverwaltungsmodul wie oben empfohlen verwaltet werden, ist die EMPFOHLENE Richtlinie für einen SSRC-Kollisionsfehler, dass der Teilnehmer die SRTP-Sitzung verlässt, da dies ein Zeichen für eine Fehlfunktion ist.