ANALISI DEL PROTOCOLLO SRP (SECURE REMOTE PASSWORD)

More documents

Recommendations

Info

il fallimento dell’autenticazione delle parti e non dà informazioni all’attacante per ottenere P. SRP-1 è immune anche dagli attacchi di Replay e, al momento, non sono note vulnerabilità rilevanti; tuttavia SRP-1 sembra comunque suscettibile ad attacchi di Clogging, così come avveniva per il protocollo di Diffie-Hellman. 4.5 Ottimizzazione del Protocollo La necessità di implementare in modo efficiente SRP in sistemi reali porta a dover considerare il numero di round necessari per completare l’autenticazione e la derivazione della chiave K; nella formulazione fin qui fatta si può osservare che servono 6 messaggi, equivalenti a 3 round (vedi tabella 5). Client Server Parametro Inviato =⇒ I ⇐= s =⇒ A ⇐= B,u =⇒ M 1 ⇐= M 2 modo si preservano i requisiti del protocollo, illustrati nel paragrafo 4.2: l’utilità di questa modifica trova ragione in SRP-6, la successiva versione del protocollo che viene descritta nel prossimo paragrafo. Sebbene nello RFC 2945 non lo si indichi esplicitamente, è ancora possibile ridurre il numero di round necessari al protocollo, riordinando la sequenza originale come mostrato nella tabella 8. Client (g,n) ←→ 1. −→ 2. x = H(s,I,P) s ←− 3. A = g a A −→ I Server ricerca (I,s,v) B = v + g b 4. u=H(A,B) ←− u=H(A,B) 5. S = (B − g x ) a+ux S = (Av u ) b 6. K = H(S) K = H(S) 7. M 1 = H(A,B,K) M −→ 1 verifica M1 M 8. verifica M 2 2 ←− B M2 = H(A,M 1 ,K) Tabella 7: Funzionamento di SRP-3. Cambiano il calcolo e l’utilizzo del parametro u. Tabella 5: I round di SRP-1 Si può dimostrare che è possibile ridurre il numero di messaggi, pur mantenendo le caratteristiche originali di SRP-1: la tabella 6 mostra la sequenza ottimizzata che sfrutta l’invio simultaneo di più parametri senza alterare i calcoli necessari. Client Server Parametro Inviato 5 SRP-3 =⇒ I,A ⇐= s,B,u =⇒ M 1 ⇐= M 2 Tabella 6: SRP-1 ottimizzato Nel settembre 2000 lo IETF ha pubblicato lo RFC 2945 [21] che definisce le specifiche del protocollo SRP-3. Le differenze rispetto a SRP-1 sono minimali e si riassumono nella modifica del calcolo di u, che avviene tramite hashing dei parametri A e B: in tal Client Server Parametro Inviato =⇒ I,A ⇐= s,B =⇒ M 1 ⇐= M 2 Tabella 8: SRP-3 ottimizzato. u non viene più inviato. 6 SRP-6 e SRP-6a Le precedenti versioni del protocollo SRP sono state migliorate sulla base di alcune considerazioni legate alla sicurezza ed all’ottimizzazione. La nuova versione, denominata SRP-6, è stata proposta in [22] e successivamente inclusa nel processo di standardizzazione IEEE P1363.2. La descrizione che segue include anche la recente versione SRP-6a, introdotta nel luglio 2005 e solo parzialmente documentata in [19]. 6.1 Attacco Two-for-One Nella sue precedenti formulazioni, SRP permette ad un attaccante di effettuare due tentativi in uno per 8
indovinare i parametri segreti ad ogni connessione; infatti, poichè vale B = v + g b = g x + g b un attaccante che si finga Authentication Server può trattare B come g y + g z inserendo in y ed z i valori corrispondenti a due presunte password P ′ e P ′′ , calcolando y = H(s,I,P ′ ) e z = H(s,I,P ′′ ) Considerando che il client sottrae g x a tale quantità (si veda la tabella 4) se y o z corrispondono alla password cercata il valore di S che verrà calcolato dal client e dall’attaccante sarà lo stesso, portando inevitabilente a concludere con successo l’autenticazione. Questa caratteristica non pone reali problemi alla sicurezza del protocollo, poichè si tratta di una situazione facilmente rilevabile e che richiede un numero non praticabile di connessioni per realizzare una quantità di tentativi significativa; tuttavia, a partire da SRP-6, è stata proposta una modifica che elimina la simmetria nel calcolo e, di conseguenza, la possibilità di realizzare questo attacco. La nuova formula utilizzata con SRP-6 è dove: B = kv + g b • k = 3 nella descrizione data nel documento [22]; • k = H(n,g) nella più recente versione SRP-6a, inclusa in [19]. ne consegue che il client, quando riceve B, dovrà calcolare S in un nuovo modo, ovvero S = (B − kg x ) a+ux 6.2 Ordinamento dei messaggi SRP-1 e SRP-3 richiedono che per entrambe le parti siano in qualche modo fissati a priori n e g; questo però, è difficile da realizzare in pratica e renderebbe comunque poco flessibile il protocollo; è quindi più naturale permettere al Server di inviare al client i parametri necessari all’avvio del protocollo, dopo il primo messaggio. Tuttavia questo approccio (mostrato in tabella 9) vanifica le ottimizzazioni di SRP-1 e SRP-3, poichè n e g sono necessari per il calcolo di A e pertento quest’ultimo non può essere inviato fino al loro ricevimento. Client Server Parametro Inviato =⇒ I ⇐= n,g,s =⇒ A ⇐= B =⇒ M 1 ⇐= M 2 Tabella 9: SRP-3 con parametri La soluzione è quella di inviare B come parte del primo messaggio del Server. Come è già stato fatto notare (paragrafo 4.2), è necessario non rivelare u sino al ricevimento del valore A e questa situazione è stata già risolta con la modifica presentata in SRP-3: u non viene più inviato in chiaro ma è derivato implicitamente dalle parti. Si ricorda infatti che per far questo client e Server calcolano u = H(A,B) basandosi quindi solo sui valori A e B rispettivamente ricevuti. In questo modo l’attacco mostrato al paragrafo 4.2 diventa difficile da realizzare, anche se il valore B del Server viene inviato prima di ricevere A; infatti un attaccante dovrebbe trovare un valore u per cui valga u = H(g a v −u ,B) ma anche scegliendo a ed u in modo arbitrario, se si utilizza una funzione di hash come SHA-1, diventa impraticabile poter ottenere il giusto valore di u e, di conseguenza, quello di a. Conseguentemente diventa possibile ottenere una sequenza ottimizzata secondo le modifiche proposte e che non incrementi i messaggi necessari (tabella 10). Client Server Parametro Inviato =⇒ I ⇐= n,g,s,B =⇒ A,M 1 ⇐= M 2 Tabella 10: SRP-6 ottimizzato 6.3 Funzionamento di SRP-6 Secondo le modifiche presentate nei paragrafi precedenti, il protocollo SRP-6 si riassume quindi nei passi illustrati nella tabella 11 (schema completo senza 9
Page 1 and 2: ANALISI DEL PROTOCOLLO SRP (SECURE
Page 3 and 4: Quindi, provando esaustivamente le
Page 5 and 6: nismo di autenticazione. Lo schema
Page 7: 4.2.1 Secondo esempio di attacco Si
Page 11 and 12: Il Dipartimento di Sistemi e Inform

ANALISI DEL PROTOCOLLO SRP (SECURE REMOTE PASSWORD)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?