Zum Hauptinhalt springen

3.2.1. Transform-independent parameters (Transformationsunabhängige Parameter)

3.2.1. Transform-independent parameters (Transformationsunabhängige Parameter)​

Transformationsunabhängige Parameter sind im kryptographischen Kontext unabhängig von den jeweiligen Verschlüsselungs- oder Authentifizierungstransformationen vorhanden, die verwendet werden. Die transformationsunabhängigen Parameter des kryptographischen Kontexts für SRTP bestehen aus:

  • einem vorzeichenlosen 32-Bit-Überlaufzähler (rollover counter, ROC), der aufzeichnet, wie oft die 16-Bit-RTP-Sequenznummer nach dem Durchlaufen von 65,535 auf Null zurückgesetzt wurde. Im Gegensatz zur Sequenznummer (SEQ), die SRTP aus dem RTP-Paket-Header extrahiert, wird der ROC von SRTP wie in Section 3.3.1 beschrieben gepflegt.

    Wir definieren den Index des SRTP-Pakets, das einem gegebenen ROC und einer RTP-Sequenznummer entspricht, als die 48-Bit-Größe

    i = 2^16 * ROC + SEQ.

  • nur für den Empfänger eine 16-Bit-Sequenznummer s_l, die als die höchste empfangene RTP-Sequenznummer betrachtet werden kann (siehe Section 3.3.1 für ihre Behandlung), die authentifiziert werden SOLLTE (SHOULD), da Nachrichtenauthentifizierung EMPFOHLEN (RECOMMENDED) ist,

  • einen Bezeichner für den Verschlüsselungsalgorithmus, d.h. die Chiffre und ihren Betriebsmodus,

  • einen Bezeichner für den Nachrichtenauthentifizierungsalgorithmus,

  • eine Wiedergabeliste (replay list), die nur vom Empfänger gepflegt wird (wenn Authentifizierung und Wiedergabeschutz bereitgestellt werden), die Indizes kürzlich empfangener und authentifizierter SRTP-Pakete enthält,

  • einen MKI-Indikator (0/1), ob ein MKI in SRTP- und SRTCP-Paketen vorhanden ist,

  • wenn der MKI-Indikator auf eins gesetzt ist, die Länge (in Oktetten) des MKI-Felds und (für den Sender) den tatsächlichen Wert des aktuell aktiven MKI (der Wert des MKI-Indikators und die Länge MÜSSEN (MUST) für die Lebensdauer des Kontexts fest bleiben),

  • den oder die Hauptschlüssel (master keys), die zufällig sein MÜSSEN (MUST) und geheim gehalten werden müssen,

  • für jeden Hauptschlüssel gibt es einen Zähler für die Anzahl der SRTP-Pakete, die mit diesem Hauptschlüssel verarbeitet (gesendet) wurden (essentiell für die Sicherheit, siehe Sections 3.3.1 und 9),

  • nichtnegative ganze Zahlen n_e und n_a, die die Länge der Sitzungsschlüssel für Verschlüsselung und Nachrichtenauthentifizierung bestimmen.

Darüber hinaus KANN (MAY) ein SRTP-Stream für jeden Hauptschlüssel die folgenden zugehörigen Werte verwenden:

  • ein Hauptsalz (master salt), das bei der Schlüsselableitung von Sitzungsschlüsseln verwendet werden soll. Dieser Wert MUSS (MUST) bei Verwendung zufällig sein, KANN (MAY) aber öffentlich sein. Die Verwendung von Hauptsalz ist stark EMPFOHLEN (RECOMMENDED), siehe Section 9.2. Ein "NULL"-Salz wird als 00...0 behandelt.

  • eine ganze Zahl aus der Menge {1,2,4,...,2^24}, die "key_derivation_rate" (Schlüsselableitungsrate), wobei ein nicht spezifizierter Wert als Null behandelt wird. Die Einschränkung auf eine Zweierpotenz vereinfacht die Implementierung der Sitzungsschlüsselableitung, siehe Section 4.3.

  • einen MKI-Wert,

  • <From, To>-Werte, die die Lebensdauer eines Hauptschlüssels spezifizieren, ausgedrückt in zwei 48-Bit-Indexwerten, innerhalb deren Bereich (einschließlich der Bereichsendpunkte) der Hauptschlüssel gültig ist. Für die Verwendung von <From, To> siehe Section 8.1.1. <From, To> ist eine Alternative zum MKI und setzt voraus, dass ein Hauptschlüssel in eins-zu-eins-Korrespondenz mit dem SRTP-Sitzungsschlüssel steht, auf dem der <From, To>-Bereich definiert ist.

SRTCP MUSS (SHALL) standardmäßig den kryptographischen Kontext mit SRTP teilen, außer:

  • es muss kein Überlaufzähler und s_l-Wert gepflegt werden, da der RTCP-Index explizit in jedem SRTCP-Paket übertragen wird,

  • eine separate Wiedergabeliste wird gepflegt (wenn Wiedergabeschutz bereitgestellt wird),

  • SRTCP pflegt einen separaten Zähler für seinen Hauptschlüssel (auch wenn der Hauptschlüssel derselbe wie der für SRTP ist, siehe unten), als Mittel zur Aufrechterhaltung einer Zählung der Anzahl der SRTCP-Pakete, die mit diesem Schlüssel verarbeitet wurden.

Beachten Sie insbesondere, dass der oder die Hauptschlüssel zwischen SRTP und dem entsprechenden SRTCP geteilt werden KÖNNEN (MAY), wenn die vordefinierten Transformationen (einschließlich der Schlüsselableitung) verwendet werden, aber der oder die Sitzungsschlüssel DÜRFEN NICHT (MUST NOT) so geteilt werden.

Darüber hinaus kann es Fälle geben (siehe Sections 8 und 9.1), in denen mehrere SRTP-Streams innerhalb einer gegebenen RTP-Sitzung, identifiziert durch ihre Synchronisationsquelle (SSRC, die Teil des RTP-Headers ist), die meisten der kryptographischen Kontextparameter (möglicherweise einschließlich Haupt- und Sitzungsschlüssel) teilen. In solchen Fällen, genau wie bei der normalen SRTP/SRTCP-Parameterfreigabe oben, MÜSSEN (MUST) dennoch separate Wiedergabelisten und Paketzähler für jeden Stream (SSRC) gepflegt werden. Außerdem MÜSSEN (MUST) dann separate SRTP-Indizes gepflegt werden.

Eine Zusammenfassung der Parameter, vordefinierten Transformationen und Standardwerte für die obigen Parameter (und andere SRTP-Parameter) finden Sie in Sections 5 und 8.2.

Letztes Update am