9.5. Integrity of the RTP payload and header (Integrità del payload e dell'intestazione RTP)
9.5. Integrity of the RTP payload and header (Integrità del payload e dell'intestazione RTP)
I messaggi SRTP sono soggetti ad attacchi sulla loro integrità e identificazione della fonte, e questi rischi sono discussi nella Sezione 9.5.1. Per proteggersi da questi attacchi, ogni flusso SRTP DOVREBBE essere protetto da HMAC-SHA1 [RFC2104] con un tag di output a 80 bit e una chiave a 160 bit, o un codice di autenticazione messaggi di forza equivalente. RTP sicuro NON DOVREBBE essere utilizzato senza autenticazione dei messaggi, tranne nelle circostanze descritte in questa sezione. È importante notare che gli algoritmi di cifratura, inclusi AES Counter Mode e f8, non forniscono autenticazione dei messaggi. SRTCP NON DEVE essere utilizzato con autenticazione debole (o NULL).
SRTP PUÒ essere utilizzato con autenticazione debole (ad esempio, un tag di autenticazione a 32 bit) o senza autenticazione (l'algoritmo di autenticazione NULL). Queste opzioni consentono di utilizzare SRTP per fornire riservatezza in situazioni in cui
- l'autenticazione debole o nulla è un rischio di sicurezza accettabile, e
- è impraticabile fornire una forte autenticazione dei messaggi.
Queste condizioni sono descritte di seguito e nella Sezione 7.5. Si noti che entrambe le condizioni DEVONO essere soddisfatte affinché l'autenticazione debole o nulla possa essere utilizzata. I rischi associati all'esercizio delle opzioni di autenticazione debole o nulla devono essere considerati da un audit di sicurezza prima del loro utilizzo per una particolare applicazione o ambiente dati i rischi, che sono discussi nella Sezione 9.5.1.
L'autenticazione debole è accettabile quando l'applicazione RTP è tale che l'effetto di una piccola frazione di falsificazioni riuscite è trascurabile. Se l'applicazione è senza stato, l'effetto di un singolo pacchetto RTP falsificato è limitato alla decodifica di quel particolare pacchetto. In questa condizione, la dimensione del tag di autenticazione DEVE garantire che solo una frazione trascurabile dei pacchetti passati all'applicazione RTP dal ricevitore SRTP possa essere falsificazioni. Questa frazione è trascurabile quando un avversario, anche se gli viene dato il controllo dei pacchetti falsificati, non è in grado di avere un impatto significativo sull'output dell'applicazione RTP (vedere l'esempio della Sezione 7.5).
L'autenticazione debole o nulla PUÒ essere accettabile quando è improbabile che un avversario possa modificare il testo cifrato in modo che si decifri in un valore intelligibile. Un caso importante è quando è difficile per un avversario acquisire i dati in chiaro RTP, poiché per molti codec, un avversario che non conosce il segnale di ingresso non può manipolare il segnale di uscita in modo controllato. In molti casi può essere difficile per l'avversario determinare il valore effettivo del testo in chiaro. Ad esempio, potrebbe essere necessario un dispositivo di spionaggio nascosto per conoscere un segnale audio o video dal vivo. Il segnale dell'avversario deve avere una qualità equivalente o superiore a quella del segnale sotto attacco, altrimenti l'avversario non avrebbe abbastanza informazioni per codificare quel segnale con il codec utilizzato dalla vittima. La previsione del testo in chiaro può anche essere particolarmente difficile per un'applicazione interattiva come una telefonata.
L'autenticazione debole o nulla NON DEVE essere utilizzata quando l'applicazione RTP prende decisioni di inoltro dati o controllo degli accessi basate sui dati RTP. In tal caso, un attaccante potrebbe essere in grado di sovvertire la riservatezza causando al ricevitore di inoltrare dati a un attaccante. Vedere la Sezione 3 di [B96] per un esempio reale di tali attacchi.
L'autenticazione nulla NON DEVE essere utilizzata quando un attacco di replay, in cui un avversario memorizza pacchetti e poi li riproduce successivamente nella sessione, potrebbe avere un impatto non trascurabile sul ricevitore. Un esempio di attacco di replay riuscito è la memorizzazione dell'output di una telecamera di sorveglianza per un periodo di tempo, seguito dall'iniezione di quell'output alla stazione di monitoraggio per evitare la sorveglianza. La cifratura non protegge da questo attacco, e l'autenticazione non nulla è RICHIESTA per sconfiggerlo.
Se la falsificazione esistenziale dei messaggi è un problema, cioè quando l'accuratezza dei dati ricevuti è di importanza non trascurabile, l'autenticazione nulla NON DEVE essere utilizzata.