9.1. SSRC collision and two-time pad (Collisione SSRC e two-time pad)
9.1. SSRC collision and two-time pad (Collisione SSRC e two-time pad)
Qualsiasi output di keystream fisso, generato dalla stessa chiave e indice, DEVE essere utilizzato per cifrare solo una volta. Il riutilizzo di tale keystream (scherzosamente chiamato sistema "two-time pad" dai crittografi) può compromettere seriamente la sicurezza. Il progetto VENONA della NSA [C99] fornisce un esempio storico di tale compromissione. È RICHIESTO che la gestione automatica delle chiavi venga utilizzata per stabilire e mantenere il materiale di chiavi SRTP e SRTCP; questo requisito serve a evitare il riutilizzo del keystream, che è più probabile che si verifichi con la gestione manuale delle chiavi. Inoltre, in SRTP, un "two-time pad" viene evitato richiedendo che la chiave, o qualche altro parametro di significato crittografico, sia unica per flusso RTP/RTCP e per pacchetto. Le trasformazioni SRTP predefinite raggiungono l'unicità dei pacchetti includendo l'indice del pacchetto e l'unicità del flusso includendo il SSRC.
Le trasformazioni predefinite (AES-CM e AES-f8) consentono la condivisione delle chiavi master tra flussi appartenenti alla stessa sessione RTP mediante l'inclusione del SSRC nell'IV. Una chiave master NON DEVE essere condivisa tra diverse sessioni RTP.
Pertanto, il SSRC DEVE essere univoco tra tutti i flussi RTP all'interno della stessa sessione RTP che condividono la stessa chiave master. RTP stesso fornisce un algoritmo per rilevare collisioni SSRC all'interno della stessa sessione RTP. Pertanto, collisioni temporanee potrebbero portare a un two-time pad temporaneo, nell'evento sfortunato che i SSRC collidano in un momento in cui i flussi hanno anche numeri di sequenza identici (che si verifica con probabilità approssimativamente 2^(-48)). Pertanto, la gestione delle chiavi DOVREBBE occuparsi di evitare tali collisioni SSRC includendo i SSRC da utilizzare nella sessione come parametri di negoziazione, assicurando proattivamente la loro unicità. Questo è un requisito forte negli scenari in cui, ad esempio, ci sono più mittenti che possono iniziare a trasmettere simultaneamente, prima che le collisioni SSRC vengano rilevate a livello RTP.
Si noti inoltre che anche con SSRC distinti, l'uso estensivo della stessa chiave potrebbe migliorare le possibilità di successo di attacchi di collisione probabilistica e compromessi tempo-memoria.
Come descritto, le chiavi master POSSONO essere condivise tra flussi appartenenti alla stessa sessione RTP, ma è RACCOMANDATO che ogni SSRC abbia la propria chiave master. Quando le chiavi master sono condivise tra partecipanti SSRC e i SSRC sono gestiti da un modulo di gestione delle chiavi come raccomandato sopra, la politica RACCOMANDATA per un errore di collisione SSRC è che il partecipante lasci la sessione SRTP poiché è un segno di malfunzionamento.