3.3.1. Packet Index Determination, and ROC, s_l Update (Paketindex-Bestimmung und ROC, s_l Aktualisierung)
3.3.1. Packet Index Determination, and ROC, s_l Update (Paketindex-Bestimmung und ROC, s_l Aktualisierung)
SRTP-Implementierungen verwenden einen "impliziten" Paketindex (implicit packet index) zur Sequenzierung, d.h. nicht der gesamte Index wird explizit im SRTP-Paket übertragen. Bei den vordefinierten Transformationen wird der Index i für Replay-Schutz (Section 3.3.2), Verschlüsselung (Section 4.1), Nachrichtenauthentifizierung (Section 4.2) und für die Schlüsselableitung (Section 4.3) verwendet.
Wenn die Sitzung beginnt, MUSS die Senderseite den Rollover-Zähler ROC (rollover counter) auf Null setzen. Jedes Mal, wenn die RTP-Sequenznummer SEQ modulo 2^16 umläuft, MUSS die Senderseite ROC modulo 2^32 um eins erhöhen (siehe Sicherheitsaspekte unten). Der Paketindex des Senders ist dann definiert als
i = 2^16 * ROC + SEQ.
Empfängerseitige Implementierungen verwenden die RTP-Sequenznummer, um den korrekten Index eines Pakets zu bestimmen, der die Position des Pakets in der Sequenz aller SRTP-Pakete ist. Ein robuster Ansatz für die ordnungsgemäße Verwendung eines Rollover-Zählers erfordert, dass seine Handhabung und Verwendung klar definiert sind. Insbesondere müssen RTP-Pakete außer der Reihe mit Sequenznummern nahe 2^16 oder Null ordnungsgemäß behandelt werden.
Die Indexschätzung basiert auf den vom Empfänger lokal gewarteten ROC- und s_l-Werten. Beim Einrichten der Sitzung MUSS der ROC auf Null gesetzt werden. Empfänger, die einer laufenden Sitzung beitreten, MÜSSEN den aktuellen ROC-Wert über Out-of-Band-Signalisierung (out-of-band signaling) wie Schlüsselverwaltungs-Signalisierung erhalten. Darüber hinaus MUSS der Empfänger s_l auf die RTP-Sequenznummer (SEQ) des ersten beobachteten SRTP-Pakets initialisieren (es sei denn, der Anfangswert wird durch Out-of-Band-Signalisierung wie Schlüsselverwaltung bereitgestellt).
Bei aufeinanderfolgenden SRTP-Paketen SOLLTE der Empfänger den Index schätzen als
i = 2^16 * v + SEQ,
wobei v aus der Menge { ROC-1, ROC, ROC+1 } (modulo 2^32) so gewählt wird, dass i am nächsten (im Sinne von modulo 2^48) am Wert 2^16 * ROC + s_l liegt (siehe Appendix A für Pseudocode).
Nachdem das Paket verarbeitet und authentifiziert wurde (wenn für SRTP-Pakete der Sitzung aktiviert), MUSS der Empfänger v verwenden, um seine s_l- und ROC-Variablen wie folgt bedingt zu aktualisieren. Wenn v=(ROC-1) mod 2^32, dann gibt es keine Aktualisierung von s_l oder ROC. Wenn v=ROC, dann wird s_l auf SEQ gesetzt, wenn und nur wenn SEQ größer als das aktuelle s_l ist; es gibt keine Änderung an ROC. Wenn v=(ROC+1) mod 2^32, dann wird s_l auf SEQ gesetzt und ROC wird auf v gesetzt.
Nachdem eine Neuverschlüsselung (re-keying) erfolgt ist (Wechsel zu einem neuen Hauptschlüssel), behält der Rollover-Zähler immer seine Wertefolge bei, d.h. er DARF NICHT auf Null zurückgesetzt werden.
Da der Rollover-Zähler 32 Bit lang und die Sequenznummer 16 Bit lang ist, beträgt die maximale Anzahl von Paketen, die zu einem gegebenen SRTP-Stream gehören und mit demselben Schlüssel gesichert werden können, bei Verwendung der vordefinierten Transformationen 2^48. Nachdem diese Anzahl von SRTP-Paketen mit einem gegebenen (Haupt- oder Sitzungs-)Schlüssel gesendet wurde, DARF der Sender keine weiteren Pakete mit diesem Schlüssel senden. (Es gibt eine ähnliche Grenze für SRTCP, die in der Praxis möglicherweise restriktiver ist, siehe Section 9.2.) Diese Einschränkung erzwingt einen Sicherheitsvorteil, indem sie eine Obergrenze für die Menge an Datenverkehr bietet, die passieren kann, bevor kryptografische Schlüssel geändert werden. Die Neuverschlüsselung (siehe Section 8.1) MUSS vor dieser Verkehrsmenge ausgelöst werden und KANN früher ausgelöst werden, z.B. für erhöhte Sicherheit und Zugriffskontrolle auf Medien. Eine wiederkehrende Schlüsselableitung mittels einer von Null verschiedenen key_derivation_rate (siehe Section 4.3) bietet ebenfalls stärkere Sicherheit, ändert jedoch nicht den oben genannten absoluten Maximalwert.
Auf der Empfängerseite gibt es eine Einschränkung beim Aktualisieren von s_l und ROC: Wenn keine Nachrichtenauthentifizierung vorhanden ist, können weder die Initialisierung von s_l noch die ROC-Aktualisierung vollständig robust gemacht werden. Der "implizite Index"-Ansatz des Empfängers funktioniert für die vordefinierten Transformationen, solange die Neuordnung und der Verlust der Pakete nicht zu groß sind und Bitfehler nicht auf ungünstige Weise auftreten. Insbesondere müssten 2^15 Pakete verloren gehen oder ein Paket müsste um 2^15 Pakete aus der Sequenz sein, bevor die Synchronisation verloren geht. Ein so drastischer Verlust oder eine solche Neuordnung würde wahrscheinlich die RTP-Anwendung selbst stören.
Der Algorithmus für die Indexschätzung und ROC-Aktualisierung ist eine Frage der Implementierung und sollte die Umgebung (z.B. Paketverlustrate) und die Fälle berücksichtigen, in denen die Synchronisation wahrscheinlich verloren geht, z.B. wenn die anfängliche Sequenznummer (von RTP zufällig gewählt) nicht im Voraus bekannt ist (nicht im Schlüsselverwaltungsprotokoll gesendet wird), aber möglicherweise nahe am Umlauf modulo 2^16 liegt.
Ein aufwendigeres und robusteres Schema als das oben angegebene ist die Handhabung des eigenen "Rollover-Zählers" von RTP, siehe Appendix A.1 von [RFC3550].