4.3. Key Derivation (Schlüsselableitung)

Unabhängig von der verwendeten Verschlüsselungs- oder Nachrichtenauthentifizierungstransformation (es kann sich um eine vordefinierte SRTP-Transformation oder eine gemäß Abschnitt 6 neu eingeführte handeln) MÜSSEN interoperable SRTP-Implementierungen die SRTP-Schlüsselableitung verwenden, um Sitzungsschlüssel zu generieren. Sobald die Schlüsselableitungsrate zu Beginn der Sitzung ordnungsgemäß signalisiert wurde, ist keine zusätzliche Kommunikation zwischen den Parteien erforderlich, die die SRTP-Schlüsselableitung verwenden.

                      packet index ---+
                                      |
                                      v
            +-----------+ master  +--------+ session encr_key
            | ext       | key     |        |---------->
            | key mgmt  |-------->|  key   | session auth_key
            | (optional |         | deriv  |---------->
            | rekey)    |-------->|        | session salt_key
            |           | master  |        |---------->
            +-----------+ salt    +--------+

Abbildung 5: SRTP-Schlüsselableitung.

Mindestens eine anfängliche Schlüsselableitung SOLL von SRTP durchgeführt werden, d. h., die erste Schlüsselableitung ist ERFORDERLICH. Weitere Anwendungen der Schlüsselableitung KÖNNEN gemäß dem Wert "key_derivation_rate" im kryptographischen Kontext durchgeführt werden. Die Schlüsselableitungsfunktion SOLL zunächst vor dem ersten Paket aufgerufen werden und dann, wenn r > 0, wird eine Schlüsselableitung durchgeführt, wann immer index mod r gleich Null ist. Dies kann als "Auffrischung" der Sitzungsschlüssel betrachtet werden. Der Wert von "key_derivation_rate" MUSS für die Lebensdauer des zugehörigen Hauptschlüssels fest bleiben.

Interoperable SRTP-Implementierungen KÖNNEN auch Sitzungssalzschlüssel für Verschlüsselungstransformationen ableiten, wie es bei beiden vordefinierten Transformationen der Fall ist.

Seien m und n positive Ganzzahlen. Eine Familie pseudozufälliger Funktionen ist eine Menge schlüsselabhängiger Funktionen {PRF_n(k,x)} derart, dass für den (geheimen) zufälligen Schlüssel k, gegeben m-Bit x, PRF_n(k,x) eine n-Bit-Zeichenkette ist, die rechnerisch nicht von zufälligen n-Bit-Zeichenketten unterscheidbar ist, siehe [HAC]. Für den Zweck der Schlüsselableitung in SRTP MUSS eine sichere PRF mit m = 128 (oder mehr) verwendet werden, und eine Standard-PRF-Transformation ist in Abschnitt 4.3.3 definiert.

Sei "a DIV t" die ganzzahlige Division von a durch t, abgerundet, und mit der Konvention, dass "a DIV 0 = 0" für alle a. Wir treffen auch die Konvention, "a DIV t" als Bitfolge derselben Länge wie a zu behandeln, und somit wird "a DIV t" im Allgemeinen führende Nullen haben.

Die Schlüsselableitung SOLL wie folgt definiert werden in Bezug auf <label>, eine 8-Bit-Konstante (siehe unten), master_salt und key_derivation_rate, wie im kryptographischen Kontext bestimmt, und index, den Paketindex (d. h. das 48-Bit ROC || SEQ für SRTP):

Sei r = index DIV key_derivation_rate (mit DIV wie oben definiert).
Sei key_id = <label> || r.
Sei x = key_id XOR master_salt, wobei key_id und master_salt so ausgerichtet sind, dass ihre am wenigsten signifikanten Bits übereinstimmen (Rechtsausrichtung).

<label> MUSS für jeden Typ von abzuleitendem Schlüssel eindeutig sein. Wir definieren derzeit <label> 0x00 bis 0x05 (siehe unten), und zukünftige Erweiterungen KÖNNEN neue Werte im Bereich 0x06 bis 0xff für andere Zwecke spezifizieren. Der n-Bit-SRTP-Schlüssel (oder Salz) für dieses Paket SOLL dann vom Hauptschlüssel k_master wie folgt abgeleitet werden:

PRF_n(k_master, x).

(Die PRF kann intern zusätzliche Formatierung und Auffüllung von x spezifizieren, siehe z. B. Abschnitt 4.3.3 für die Standard-PRF.)

Die Sitzungsschlüssel und das Salz SOLLEN nun wie folgt abgeleitet werden:

k_e (SRTP-Verschlüsselung): <label> = 0x00, n = n_e.
k_a (SRTP-Nachrichtenauthentifizierung): <label> = 0x01, n = n_a.
k_s (SRTP-Salzschlüssel): <label> = 0x02, n = n_s.

wobei n_e, n_s und n_a aus dem kryptographischen Kontext stammen.

Der Hauptschlüssel und das Hauptsalz MÜSSEN zufällig sein, aber das Hauptsalz KANN öffentlich sein.

Beachten Sie, dass für eine key_derivation_rate von 0 die Anwendung der Schlüsselableitung genau einmal erfolgen SOLL.

Die obige Definition von DIV dient rein der notationellen Bequemlichkeit. Für ein von Null verschiedenes t unter der Menge der zulässigen Schlüsselableitungsraten kann "a DIV t" als Rechtsverschiebung um den Logarithmus zur Basis 2 von t implementiert werden. Die Ableitungsoperation wird weiter erleichtert, wenn die Raten als Potenzen von 256 gewählt werden, aber diese Granularität wurde als zu grob angesehen, um eine Anforderung dieser Spezifikation zu sein.

Die Obergrenze für die Anzahl der Pakete, die mit demselben Hauptschlüssel gesichert werden können (siehe Abschnitt 9.2), ist unabhängig von der Schlüsselableitung.

4.3. Key Derivation (Schlüsselableitung)​

4.3. Key Derivation (Schlüsselableitung)