9.2. Key Usage (Utilizzo delle chiavi)
9.2. Key Usage (Utilizzo delle chiavi)
La dimensione effettiva della chiave è determinata (limitata superiormente) dalla dimensione della chiave master e, per la cifratura, dalla dimensione della chiave di salting. Qualsiasi cifrario a flusso additivo è vulnerabile ad attacchi che utilizzano conoscenze statistiche sulla sorgente di testo in chiaro per abilitare attacchi di collisione di chiavi e compromessi tempo-memoria [MF00] [H80] [BS00]. Questi attacchi sfruttano le caratteristiche comuni tra i testi in chiaro e forniscono un modo per un crittoanalista di ammortizzare lo sforzo computazionale della decifratura su molte chiavi o su molti byte di output, riducendo così la dimensione effettiva della chiave del cifrario. Un'analisi dettagliata di questi attacchi e della loro applicabilità alla cifratura del traffico Internet è fornita in [MF00]. In sintesi, la dimensione effettiva della chiave di SRTP quando utilizzato in un sistema di sicurezza in cui vengono utilizzate m chiavi distinte, è uguale alla dimensione della chiave del cifrario meno il logaritmo (base due) di m. La protezione contro tali attacchi può essere fornita semplicemente aumentando la dimensione delle chiavi utilizzate, che qui può essere realizzata mediante l'uso della chiave di salting. Si noti che la chiave di salting DEVE essere casuale ma PUÒ essere pubblica. Una dimensione del salt di (la dimensione suggerita) 112 bit protegge contro attacchi in scenari in cui vengono utilizzate al massimo 2^112 chiavi. Questo è sufficiente per tutti gli scopi pratici.
Le implementazioni DOVREBBERO utilizzare chiavi più grandi possibile. Si noti che in molti casi l'aumento della dimensione della chiave di un cifrario non influisce sul throughput di quel cifrario.
L'uso degli indici SRTP e SRTCP nelle trasformazioni predefinite fissa il numero massimo di pacchetti che possono essere protetti con la stessa chiave. Questo limite è fissato a 2^48 pacchetti SRTP per un flusso SRTP e 2^31 pacchetti SRTCP, quando SRTP e SRTCP sono considerati indipendentemente. A causa ad esempio del rinnovamento della chiave, il raggiungimento di questo limite può o meno coincidere con il wraparound degli indici, e quindi il mittente DEVE tenere i conteggi dei pacchetti. Tuttavia, quando le chiavi di sessione per flussi SRTP e SRTCP correlati sono derivate dalla stessa chiave master (il comportamento predefinito, Sezione 4.3), il limite superiore che deve essere considerato è in pratica il minimo delle due quantità. Cioè, quando 2^48 pacchetti SRTP o 2^31 pacchetti SRTCP sono stati protetti con la stessa chiave (qualunque si verifichi prima), la gestione delle chiavi DEVE essere chiamata per fornire nuove chiavi master (le chiavi precedentemente memorizzate e utilizzate NON DEVONO essere utilizzate di nuovo), o la sessione DEVE essere terminata. Se un mittente di RTCP scopre che il mittente di SRTP (o SRTCP) non ha aggiornato la chiave master o di sessione prima di inviare 2^48 pacchetti SRTP (o 2^31 pacchetti SRTCP) appartenenti allo stesso flusso SRTP (SRTCP), spetta alla politica di sicurezza del mittente RTCP decidere come comportarsi, ad esempio se un pacchetto RTCP BYE debba essere inviato e/o se l'evento debba essere registrato.
Nota: nella maggior parte delle applicazioni tipiche (assumendo almeno un pacchetto RTCP ogni 128.000 pacchetti RTP), sarà l'indice SRTCP a raggiungere per primo il limite superiore, sebbene il tempo fino a quando ciò si verifica sia molto lungo: anche a 200 pacchetti SRTCP/sec, lo spazio di indici 2^31 di SRTCP è sufficiente per proteggere circa 4 mesi di comunicazione.
Si noti che se la chiave master deve essere condivisa tra flussi SRTP all'interno della stessa sessione RTP (Sezione 9.1), sebbene i limiti sopra riportati siano su base per flusso (cioè per SSRC), il mittente DEVE basare la decisione di rinnovamento della chiave sul flusso il cui spazio di numeri di sequenza viene esaurito per primo.
La derivazione della chiave limita la quantità di testo in chiaro che viene cifrato con una chiave di sessione fissa e reso disponibile a un attaccante per l'analisi, ma la derivazione della chiave non estende la durata della chiave master. Per capire questo, considerate semplicemente i nostri requisiti per evitare il two-time pad: due pacchetti distinti DEVONO essere elaborati o con IV distinti o con chiavi di sessione distinte, e sia la distinzione dell'IV che delle chiavi di sessione sono (per le trasformazioni predefinite) dipendenti dalla distinzione degli indici dei pacchetti.
Si noti che con la derivazione della chiave, la dimensione effettiva della chiave è al massimo quella della chiave master, anche se la chiave di sessione derivata è notevolmente più lunga. Con la trasformazione di autenticazione predefinita, la chiave di autenticazione di sessione è di 160 bit, ma la chiave master per impostazione predefinita è solo di 128 bit. Questa scelta progettuale è stata fatta per conformarsi a certe raccomandazioni in [RFC2104] in modo che un'implementazione HMAC esistente possa essere integrata in SRTP senza problemi. Poiché la dimensione del tag predefinita è di 80 bit, per le applicazioni in questione è anche considerata accettabile dal punto di vista della sicurezza. Gli utenti che hanno preoccupazioni su questo sono RACCOMANDATI di utilizzare invece una chiave master di 192 bit nella derivazione della chiave. È stato tuttavia scelto di non imporre chiavi di 192 bit poiché le implementazioni AES esistenti da utilizzare nella derivazione della chiave potrebbero non supportare sempre lunghezze di chiave diverse da 128 bit. Poiché AES non è definito (o analizzato correttamente) per l'uso con chiavi di 160 bit, NON È RACCOMANDATO che vengano utilizzati schemi di padding di chiavi ad-hoc per riempire chiavi più corte a 192 o 256 bit.