8. Key Management Considerations (Überlegungen zur Schlüsselverwaltung)
8. Key Management Considerations (Überlegungen zur Schlüsselverwaltung)
Es gibt aufkommende Schlüsselverwaltungsstandards [MIKEY] [KEYMGT] [SDMS] zur Etablierung eines SRTP-Kryptografiekontexts (z.B. eines SRTP-Hauptschlüssels). Sowohl proprietäre als auch offene Schlüsselverwaltungsmethoden werden wahrscheinlich für Telefonieanwendungen [MIKEY] [KINK] und Multicast-Anwendungen [GDOI] verwendet. Dieser Abschnitt bietet Anleitungen für Schlüsselverwaltungssysteme, die SRTP-Sitzungen bedienen.
Für die Initialisierung SOLLTE einer interoperablen SRTP-Implementierung der SSRC bereitgestellt werden und KANN die anfängliche RTP-Sequenznummer für den RTP-Stream durch die Schlüsselverwaltung bereitgestellt werden (daher hat die Schlüsselverwaltung eine Abhängigkeit von RTP-Betriebsparametern). Das Senden der RTP-Sequenznummer in der Schlüsselverwaltung kann nützlich sein, z.B. wenn die anfängliche Sequenznummer nahe am Überlauf ist (um Synchronisationsprobleme zu vermeiden) und um die aktuelle Sequenznummer an einen beitretenden Endpunkt zu kommunizieren (um dessen Replay-Liste korrekt zu initialisieren).
Wenn die vordefinierten Transformationen verwendet werden, erlaubt SRTP das Teilen desselben Hauptschlüssels zwischen SRTP/SRTCP-Streams, die zur selben RTP-Sitzung gehören.
Erstens ist das Teilen zwischen SRTP-Streams, die zur selben RTP-Sitzung gehören, sicher, wenn das Design des Synchronisationsmechanismus, d.h. des IV, die Wiederverwendung des Schlüsselstroms vermeidet (das Two-Time-Pad, Abschnitt 9.1). Dies wird durch die Tatsache sichergestellt, dass RTP eindeutige SSRCs für Streams bereitstellt, die zur selben RTP-Sitzung gehören. Siehe Abschnitt 9.1 für weitere Diskussion.
Zweitens ist das Teilen zwischen SRTP und dem entsprechenden SRTCP sicher. Die Tatsache, dass ein SRTP-Stream und sein zugehöriger SRTCP-Stream beide denselben SSRC tragen, stellt aufgrund der Schlüsselableitung kein Problem für das Two-Time-Pad dar. Daher KÖNNEN SRTP und SRTCP, die einer RTP-Sitzung entsprechen, Hauptschlüssel teilen (wie sie es standardmäßig tun).
Beachten Sie, dass die Nachrichtenauthentifizierung auch eine Abhängigkeit von der SSRC-Eindeutigkeit hat, die nicht mit dem Problem der Schlüsselstrom-Wiederverwendung zusammenhängt: SRTP-Streams, die unter demselben Schlüssel authentifiziert werden, MÜSSEN einen unterschiedlichen SSRC haben, um den Absender der Nachricht zu identifizieren. Diese Anforderung ist notwendig, weil der SSRC das kryptografisch authentifizierte Feld ist, das zur Unterscheidung zwischen verschiedenen SRTP-Streams verwendet wird. Würden zwei Streams identische SSRC-Werte verwenden, könnte ein Angreifer Nachrichten von einem Stream in den anderen ersetzen, ohne entdeckt zu werden.
SRTP/SRTCP DARF NICHT unter anderen Umständen als den oben genannten Hauptschlüssel teilen, d.h. zwischen SRTP und seinem entsprechenden SRTCP und zwischen Streams, die zur selben RTP-Sitzung gehören.