4.1.1. AES in Counter Mode (AES in modalità contatore)
4.1.1. AES in Counter Mode (AES in modalità contatore)
Concettualmente, la modalità contatore [AES-CTR] consiste nel cifrare interi successivi. La definizione effettiva è un po' più complicata, al fine di randomizzare il punto di partenza della sequenza di interi. Ogni pacchetto è cifrato con un segmento di flusso di chiavi distinto, che DEVE essere calcolato come segue.
Un segmento di flusso di chiavi DEVE essere la concatenazione dei blocchi di output di 128 bit del cifrario AES nella direzione di cifratura, utilizzando la chiave k = k_e, in cui gli indici di blocco sono in ordine crescente. Simbolicamente, ogni segmento di flusso di chiavi appare come
E(k, IV) || E(k, IV + 1 mod 2^128) || E(k, IV + 2 mod 2^128) ...
dove il valore intero a 128 bit IV DEVE essere definito dal SSRC, dall'indice del pacchetto SRTP i, e dalla chiave di salatura di sessione SRTP k_s, come di seguito.
IV = (k_s * 2^16) XOR (SSRC * 2^64) XOR (i * 2^16)
Ciascuno dei tre termini nella somma XOR sopra è riempito con tanti zeri iniziali quanti sono necessari per rendere l'operazione ben definita, considerata come un valore a 128 bit.
L'inclusione del SSRC consente l'uso della stessa chiave per proteggere flussi SRTP distinti all'interno della stessa sessione RTP, vedere le avvertenze di sicurezza nella Sezione 9.1.
Nel caso di SRTCP, DEVE essere utilizzato il SSRC del primo header del pacchetto composto, i DEVE essere l'indice SRTCP a 31 bit e k_e, k_s DEVONO essere sostituiti dalla chiave di sessione di cifratura SRTCP e dal sale.
Si noti che il valore iniziale, IV, è fisso per ogni pacchetto ed è formato "riservando" 16 zeri nei bit meno significativi per lo scopo del contatore. Il numero di blocchi di flusso di chiavi generati per qualsiasi valore fisso di IV NON DEVE superare 2^16 per evitare il riutilizzo del flusso di chiavi, vedere di seguito. L'AES ha una dimensione di blocco di 128 bit, quindi 2^16 blocchi di output sono sufficienti per generare i 2^23 bit di flusso di chiavi necessari per cifrare il più grande pacchetto RTP possibile (ad eccezione dei "jumbogrammi" IPv6 [RFC2675], che non è probabile vengano utilizzati per il traffico multimediale basato su RTP). Questa restrizione sulla dimensione massima in bit del pacchetto che può essere cifrato garantisce la sicurezza del metodo di cifratura limitando l'efficacia degli attacchi probabilistici [BDJR].
Per una particolare chiave in modalità contatore, ogni valore IV utilizzato come input DEVE essere distinto, al fine di evitare l'esposizione alla sicurezza di una situazione di one-time pad utilizzato due volte (Sezione 9.1). Per soddisfare questo vincolo, un'implementazione DEVE garantire che la combinazione dell'indice del pacchetto SRTP di ROC || SEQ, e del SSRC utilizzato nella costruzione dell'IV siano distinti per qualsiasi chiave particolare. Il mancato assicuramento di questa unicità potrebbe essere catastrofico per Secure RTP. Ciò contrasta con la situazione per RTP stesso, che può essere in grado di tollerare tali fallimenti. È RACCOMANDATO che, se è presente un modulo di sicurezza dedicato, i numeri di sequenza RTP e il SSRC siano generati o controllati da quel modulo (cioè, l'elaborazione del numero di sequenza e del SSRC in un sistema SRTP deve essere protetta così come la chiave).