9.2. Key Usage (Schlüsselverwendung)
9.2. Key Usage (Schlüsselverwendung)
Die effektive Schlüsselgröße wird durch die Größe des Hauptschlüssels und für die Verschlüsselung durch die Größe des Salting-Schlüssels bestimmt (obere Grenze). Jede additive Stream-Chiffre ist anfällig für Angriffe, die statistisches Wissen über die Klartext-Quelle nutzen, um Schlüsselkollisions- und Zeit-Speicher-Kompromiss-Angriffe [MF00] [H80] [BS00] zu ermöglichen. Diese Angriffe nutzen Gemeinsamkeiten zwischen Klartexten aus und bieten einem Kryptoanalytiker eine Möglichkeit, den Rechenaufwand für die Entschlüsselung über viele Schlüssel oder über viele Bytes der Ausgabe zu amortisieren und damit die effektive Schlüsselgröße der Chiffre zu reduzieren. Eine detaillierte Analyse dieser Angriffe und ihrer Anwendbarkeit auf die Verschlüsselung von Internetverkehr wird in [MF00] bereitgestellt. Zusammenfassend ist die effektive Schlüsselgröße von SRTP bei Verwendung in einem Sicherheitssystem, in dem m verschiedene Schlüssel verwendet werden, gleich der Schlüsselgröße der Chiffre abzüglich des Logarithmus (Basis zwei) von m. Schutz gegen solche Angriffe kann einfach durch Erhöhung der Größe der verwendeten Schlüssel bereitgestellt werden, was hier durch die Verwendung des Salting-Schlüssels erreicht werden kann. Beachten Sie, dass der Salting-Schlüssel zufällig sein MUSS, aber öffentlich sein KANN. Eine Salzgröße von (der empfohlenen) Größe 112 Bit schützt gegen Angriffe in Szenarien, in denen höchstens 2^112 Schlüssel verwendet werden. Dies ist für alle praktischen Zwecke ausreichend.
Implementierungen SOLLTEN so große Schlüssel wie möglich verwenden. Bitte beachten Sie, dass in vielen Fällen die Erhöhung der Schlüsselgröße einer Chiffre den Durchsatz dieser Chiffre nicht beeinflusst.
Die Verwendung der SRTP- und SRTCP-Indizes in den vordefinierten Transformationen legt die maximale Anzahl von Paketen fest, die mit demselben Schlüssel gesichert werden können. Diese Grenze ist auf 2^48 SRTP-Pakete für einen SRTP-Stream und 2^31 SRTCP-Pakete festgelegt, wenn SRTP und SRTCP unabhängig betrachtet werden. Aufgrund beispielsweise der Schlüsselerneuerung kann das Erreichen dieser Grenze mit dem Überlauf der Indizes zusammenfallen oder nicht, daher MUSS der Sender Paketzahlen führen. Wenn jedoch die Sitzungsschlüssel für verwandte SRTP- und SRTCP-Streams aus demselben Hauptschlüssel abgeleitet werden (das Standardverhalten, Abschnitt 4.3), ist die zu berücksichtigende Obergrenze in der Praxis das Minimum der beiden Mengen. Das heißt, wenn 2^48 SRTP-Pakete oder 2^31 SRTCP-Pakete mit demselben Schlüssel gesichert wurden (je nachdem, was zuerst eintritt), MUSS die Schlüsselverwaltung aufgerufen werden, um neue Hauptschlüssel bereitzustellen (zuvor gespeicherte und verwendete Schlüssel DÜRFEN NICHT erneut verwendet werden), oder die Sitzung MUSS beendet werden. Wenn ein Sender von RTCP feststellt, dass der Sender von SRTP (oder SRTCP) den Haupt- oder Sitzungsschlüssel nicht vor dem Senden von 2^48 SRTP- (oder 2^31 SRTCP-) Paketen, die zum selben SRTP- (SRTCP-) Stream gehören, aktualisiert hat, liegt es an der Sicherheitsrichtlinie des RTCP-Senders, wie zu verfahren ist, z.B. ob ein RTCP BYE-Paket gesendet werden sollte und/oder ob das Ereignis protokolliert werden sollte.
Hinweis: In den meisten typischen Anwendungen (vorausgesetzt mindestens ein RTCP-Paket für jede 128.000 RTP-Pakete) wird es der SRTCP-Index sein, der zuerst die Obergrenze erreicht, obwohl die Zeit bis dies eintritt sehr lang ist: Selbst bei 200 SRTCP-Paketen/Sek. reicht der 2^31-Indexraum von SRTCP aus, um etwa 4 Monate Kommunikation zu sichern.
Beachten Sie, dass wenn der Hauptschlüssel zwischen SRTP-Streams innerhalb derselben RTP-Sitzung geteilt werden soll (Abschnitt 9.1), obwohl die obigen Grenzen auf einer Pro-Stream-Basis (d.h. pro SSRC) sind, der Sender die Schlüsselerneuerungs-Entscheidung auf den Stream basieren MUSS, dessen Sequenznummernraum zuerst erschöpft ist.
Die Schlüsselableitung begrenzt die Menge an Klartext, die mit einem festen Sitzungsschlüssel verschlüsselt und einem Angreifer zur Analyse zur Verfügung gestellt wird, aber die Schlüsselableitung verlängert nicht die Lebensdauer des Hauptschlüssels. Um dies zu sehen, betrachten Sie einfach unsere Anforderungen zur Vermeidung des Two-Time-Pads: Zwei verschiedene Pakete MÜSSEN entweder mit verschiedenen IVs oder mit verschiedenen Sitzungsschlüsseln verarbeitet werden, und sowohl die Unterscheidbarkeit des IV als auch der Sitzungsschlüssel sind (für die vordefinierten Transformationen) von der Unterscheidbarkeit der Paketindizes abhängig.
Beachten Sie, dass bei der Schlüsselableitung die effektive Schlüsselgröße höchstens die des Hauptschlüssels ist, selbst wenn der abgeleitete Sitzungsschlüssel erheblich länger ist. Bei der vordefinierten Authentifizierungs-Transformation ist der Sitzungs-Authentifizierungsschlüssel 160 Bit, aber der Hauptschlüssel ist standardmäßig nur 128 Bit. Diese Designentscheidung wurde getroffen, um bestimmte Empfehlungen in [RFC2104] zu erfüllen, damit eine bestehende HMAC-Implementierung problemlos in SRTP eingebunden werden kann. Da die Standard-Tag-Größe 80 Bit beträgt, wird dies für die beabsichtigten Anwendungen auch aus Sicherheitssicht als akzeptabel angesehen. Benutzer, die Bedenken hierüber haben, wird EMPFOHLEN, stattdessen einen 192-Bit-Hauptschlüssel in der Schlüsselableitung zu verwenden. Es wurde jedoch gewählt, 192-Bit-Schlüssel nicht vorzuschreiben, da bestehende AES-Implementierungen, die in der Schlüsselableitung verwendet werden sollen, möglicherweise nicht immer Schlüssellängen außer 128 Bit unterstützen. Da AES nicht für die Verwendung mit 160-Bit-Schlüsseln definiert (oder ordnungsgemäß analysiert) ist, wird es NICHT EMPFOHLEN, dass Ad-hoc-Schlüssel-Padding-Schemata verwendet werden, um kürzere Schlüssel auf 192 oder 256 Bit aufzufüllen.