4.2. Sequence Number and Epoch (Sequenznummer und Epoche)
4.2. Sequence Number and Epoch (Sequenznummer und Epoche)
DTLS verwendet eine explizite oder teilweise explizite Sequenznummer anstelle einer impliziten, die im sequence_number-Feld des Datensatzes übertragen wird. Sequenznummern werden für jede Epoche separat verwaltet, wobei jede sequence_number für jede Epoche zunächst 0 ist.
Die Epochennummer ist anfänglich Null und wird jedes Mal inkrementiert, wenn sich das Schlüsselmaterial ändert und ein Sender eine erneute Schlüsselung anstrebt. Weitere Details werden in Abschnitt 6.1 bereitgestellt.
4.2.1. Processing Guidelines (Verarbeitungsrichtlinien)
Da DTLS-Datensätze neu angeordnet werden können, kann ein Datensatz aus Epoche M empfangen werden, nachdem Epoche N (wobei N > M) begonnen hat. Implementierungen SOLLTEN Datensätze aus früheren Epochen verwerfen, KÖNNEN jedoch wählen, Schlüsselmaterial aus früheren Epochen bis zur Standard-MSL, die für TCP [RFC0793] spezifiziert ist, beizubehalten, um Paket-Neuordnung zu ermöglichen. (Beachten Sie, dass die Absicht hier ist, dass Implementierer die aktuellen Richtlinien der IETF für MSL verwenden, wie in [RFC0793] oder Nachfolgern spezifiziert, und nicht dass sie versuchen, die MSL abzufragen, die der System-TCP-Stack verwendet.)
Umgekehrt ist es möglich, dass Datensätze, die mit der neuen Epoche geschützt sind, vor dem Abschluss eines Handshakes empfangen werden. Beispielsweise kann der Server seine Finished-Nachricht senden und dann mit der Datenübertragung beginnen. Implementierungen KÖNNEN solche Datensätze entweder puffern oder verwerfen, obwohl sie, wenn DTLS über zuverlässige Transporte (z.B. SCTP [RFC4960]) verwendet wird, gepuffert und verarbeitet werden SOLLTEN, sobald der Handshake abgeschlossen ist. Beachten Sie, dass die Einschränkungen von TLS, wann Datensätze gesendet werden dürfen, weiterhin gelten, und der Empfänger behandelt die Datensätze so, als wären sie in der richtigen Reihenfolge gesendet worden.
Implementierungen MÜSSEN Wiederholungsübertragungen verlorener Nachrichten unter Verwendung derselben Epoche und desselben Schlüsselmaterials wie die ursprüngliche Übertragung senden.
Implementierungen MÜSSEN entweder eine Assoziation aufgeben oder neu verschlüsseln, bevor sie zulassen, dass die Sequenznummer umläuft.
Implementierungen DÜRFEN NICHT zulassen, dass die Epoche umläuft, sondern MÜSSEN stattdessen eine neue Assoziation erstellen und die alte Assoziation beenden.
4.2.2. Reconstructing the Sequence Number and Epoch (Rekonstruktion der Sequenznummer und Epoche)
Beim Empfang geschützter DTLS-Datensätze hat der Empfänger keinen vollständigen Epochen- oder Sequenznummernwert im Datensatz, und es gibt daher einige Möglichkeiten für Mehrdeutigkeit. Da die vollständige Sequenznummer zur Berechnung der datensatzspezifischen Nonce verwendet wird und die Epoche die Schlüssel bestimmt, führt das Versagen, diese Werte zu rekonstruieren, zum Versagen, den Datensatz zu entschlüsseln, und daher KÖNNEN Implementierungen einen Mechanismus ihrer Wahl verwenden, um die vollständigen Werte zu bestimmen. Dieser Abschnitt bietet einen Algorithmus, der vergleichsweise einfach ist und dem Implementierungen EMPFOHLEN werden zu folgen.
Wenn die Epochenbits mit denen der aktuellen Epoche übereinstimmen, dann SOLLTEN Implementierungen die Sequenznummer rekonstruieren, indem sie die vollständige Sequenznummer berechnen, die numerisch am nächsten zu eins plus der Sequenznummer des höchsten erfolgreich entschlüsselten Datensatzes in der aktuellen Epoche liegt.
Während der Handshake-Phase geben die Epochenbits eindeutig den zu verwendenden korrekten Schlüssel an. Nach Abschluss des Handshakes, wenn die Epochenbits nicht mit denen der aktuellen Epoche übereinstimmen, SOLLTEN Implementierungen die jüngste vergangene Epoche verwenden, die übereinstimmende Bits hat, und dann die Sequenznummer für diese Epoche wie oben beschrieben rekonstruieren.
4.2.3. Record Number Encryption (Datensatznummernverschlüsselung)
In DTLS 1.3 werden, wenn Datensätze verschlüsselt werden, auch Datensatz-Sequenznummern verschlüsselt. Das grundlegende Muster ist, dass der zugrunde liegende Verschlüsselungsalgorithmus, der mit dem AEAD-Algorithmus verwendet wird, verwendet wird, um eine Maske zu erzeugen, die dann mit der Sequenznummer XOR-verknüpft wird.
Wenn das AEAD auf AES basiert, dann wird die Maske durch Berechnung von AES-ECB auf den ersten 16 Bytes des Chiffretexts erzeugt:
Mask = AES-ECB(sn_key, Ciphertext[0..15])
Wenn das AEAD auf ChaCha20 basiert, dann wird die Maske erzeugt, indem die ersten 4 Bytes des Chiffretexts als Blockzähler und die nächsten 12 Bytes als Nonce behandelt werden und diese an die ChaCha20-Blockfunktion übergeben werden (Abschnitt 2.3 von [CHACHA]):
Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
Der sn_key wird wie folgt berechnet:
[sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)
[sender] bezeichnet die Sendeseite. Der zu verwendende Secret-Wert pro Epoche ist in Abschnitt 7.3 von [TLS13] beschrieben. Beachten Sie, dass für jede Epoche ein neuer Schlüssel verwendet wird: Da die Epoche im Klartext gesendet wird, führt dies nicht zu Mehrdeutigkeit.
Die verschlüsselte Sequenznummer wird durch XOR-Verknüpfung der führenden Bytes der Maske mit der Drahtdarstellung der Sequenznummer berechnet. Die Entschlüsselung wird durch denselben Prozess erreicht.
Dieses Verfahren erfordert, dass die Chiffretextlänge mindestens 16 Bytes beträgt. Empfänger MÜSSEN kürzere Datensätze ablehnen, als ob sie die Entschlüsselung nicht bestanden hätten, wie in Abschnitt 4.5.2 beschrieben. Sender MÜSSEN kurze Klartexte auffüllen (unter Verwendung des konventionellen Datensatzauffüllungsmechanismus), um einen Chiffretext geeigneter Länge zu erstellen. Beachten Sie, dass die meisten DTLS-AEAD-Algorithmen ein 16-Byte-Authentifizierungs-Tag haben und keine Auffüllung benötigen. Einige Algorithmen wie TLS_AES_128_CCM_8_SHA256 haben jedoch ein kürzeres Authentifizierungs-Tag und erfordern möglicherweise Auffüllung für kurze Eingaben.
Zukünftige Cipher-Suiten, die nicht auf AES oder ChaCha20 basieren, MÜSSEN ihre eigene Datensatz-Sequenznummernverschlüsselung definieren, um mit DTLS verwendet zu werden.
Beachten Sie, dass die Sequenznummernverschlüsselung nur auf die DTLSCiphertext-Struktur angewendet wird und nicht auf die DTLSPlaintext-Struktur, obwohl diese auch eine Sequenznummer enthält.