3.3.1. Packet Index Determination, and ROC, s_l Update (Determinazione dell'indice del pacchetto e aggiornamento di ROC, s_l)

3.3.1. Packet Index Determination, and ROC, s_l Update (Determinazione dell'indice del pacchetto e aggiornamento di ROC, s_l)

Le implementazioni SRTP utilizzano un indice di pacchetto "implicito" (implicit packet index) per il sequenziamento, cioè non tutto l'indice è esplicitamente trasportato nel pacchetto SRTP. Per le trasformazioni predefinite, l'indice i viene utilizzato nella protezione contro il replay (Section 3.3.2), nella cifratura (Section 4.1), nell'autenticazione del messaggio (Section 4.2) e per la derivazione della chiave (Section 4.3).

Quando inizia la sessione, il lato mittente DEVE impostare il contatore di rollover ROC (rollover counter) a zero. Ogni volta che il numero di sequenza RTP, SEQ, si azzera modulo 2^16, il lato mittente DEVE incrementare ROC di uno, modulo 2^32 (vedere gli aspetti di sicurezza di seguito). L'indice del pacchetto del mittente è quindi definito come

i = 2^16 * ROC + SEQ.

Le implementazioni lato ricevitore utilizzano il numero di sequenza RTP per determinare l'indice corretto di un pacchetto, che è la posizione del pacchetto nella sequenza di tutti i pacchetti SRTP. Un approccio robusto per l'uso corretto di un contatore di rollover richiede che la sua gestione e utilizzo siano ben definiti. In particolare, i pacchetti RTP fuori ordine con numeri di sequenza vicini a 2^16 o zero devono essere gestiti correttamente.

La stima dell'indice si basa sui valori ROC e s_l mantenuti localmente dal ricevitore. All'avvio della sessione, il ROC DEVE essere impostato a zero. I ricevitori che si uniscono a una sessione in corso DEVONO ricevere il valore ROC corrente utilizzando segnalazione fuori banda (out-of-band signaling) come la segnalazione di gestione delle chiavi. Inoltre, il ricevitore DEVE inizializzare s_l al numero di sequenza RTP (SEQ) del primo pacchetto SRTP osservato (a meno che il valore iniziale non sia fornito da segnalazione fuori banda come la gestione delle chiavi).

Sui pacchetti SRTP consecutivi, il ricevitore DOVREBBE stimare l'indice come

i = 2^16 * v + SEQ,

dove v è scelto dall'insieme { ROC-1, ROC, ROC+1 } (modulo 2^32) in modo che i sia il più vicino (nel senso modulo 2^48) al valore 2^16 * ROC + s_l (vedere Appendix A per lo pseudocodice).

Dopo che il pacchetto è stato elaborato e autenticato (quando abilitato per i pacchetti SRTP della sessione), il ricevitore DEVE utilizzare v per aggiornare condizionalmente le sue variabili s_l e ROC come segue. Se v=(ROC-1) mod 2^32, allora non c'è aggiornamento di s_l o ROC. Se v=ROC, allora s_l è impostato a SEQ se e solo se SEQ è maggiore dell'attuale s_l; non c'è cambiamento a ROC. Se v=(ROC+1) mod 2^32, allora s_l è impostato a SEQ e ROC è impostato a v.

Dopo che si verifica una richiavatura (re-keying) (cambio a una nuova chiave master), il contatore di rollover mantiene sempre la sua sequenza di valori, cioè NON DEVE essere reimpostato a zero.

Poiché il contatore di rollover è lungo 32 bit e il numero di sequenza è lungo 16 bit, il numero massimo di pacchetti appartenenti a un dato flusso SRTP che possono essere protetti con la stessa chiave è 2^48 utilizzando le trasformazioni predefinite. Dopo che quel numero di pacchetti SRTP è stato inviato con una data chiave (master o di sessione), il mittente NON DEVE inviare ulteriori pacchetti con quella chiave. (Esiste un limite simile per SRTCP, che in pratica può essere più restrittivo, vedere Section 9.2.) Questa limitazione impone un vantaggio di sicurezza fornendo un limite superiore sulla quantità di traffico che può passare prima che le chiavi crittografiche vengano cambiate. La richiavatura (vedere Section 8.1) DEVE essere attivata prima di questa quantità di traffico, e PUÒ essere attivata prima, ad esempio, per una maggiore sicurezza e controllo degli accessi ai media. La derivazione ricorrente delle chiavi mediante un key_derivation_rate non nullo (vedere Section 4.3) fornisce anche una sicurezza più forte ma non cambia il valore massimo assoluto sopra indicato.

Sul lato ricevitore, c'è un avvertimento per l'aggiornamento di s_l e ROC: se l'autenticazione del messaggio non è presente, né l'inizializzazione di s_l né l'aggiornamento di ROC possono essere resi completamente robusti. L'approccio "indice implicito" del ricevitore funziona per le trasformazioni predefinite finché il riordino e la perdita dei pacchetti non sono troppo grandi e gli errori di bit non si verificano in modi sfortunati. In particolare, 2^15 pacchetti dovrebbero andare persi, o un pacchetto dovrebbe essere fuori sequenza di 2^15 pacchetti prima che la sincronizzazione venga persa. Una perdita o un riordino così drastico potrebbe probabilmente interrompere l'applicazione RTP stessa.

L'algoritmo per la stima dell'indice e l'aggiornamento di ROC è una questione di implementazione e dovrebbe prendere in considerazione l'ambiente (ad esempio, il tasso di perdita di pacchetti) e i casi in cui è probabile che la sincronizzazione venga persa, ad esempio, quando il numero di sequenza iniziale (scelto casualmente da RTP) non è noto in anticipo (non inviato nel protocollo di gestione delle chiavi) ma potrebbe essere vicino all'azzeramento modulo 2^16.

Uno schema più elaborato e più robusto di quello fornito sopra è la gestione del proprio "contatore di rollover" di RTP, vedere Appendix A.1 di [RFC3550].